One of the new features in SproutCore v1.10.0 was a PhantomJS unit test runner. It allowed us to automate SproutCore’s own framework unit tests, giving us awesome continuous integration support right in GitHub via the great Travis-CI service.

If you use CoreTest, SproutCore’s built-in (QUnit-like) unit test framework, then you can also use this to run your own tests from the command line – meaning you can automate it, and hook it up to your own CI scaffolding. It’s impossible to overstate the impact that continuous, automatic unit testing has on the quality and stability of your codebase.

Prerequistites

You will need to have PhantomJS installed before using the test runner. Full instructions for this can be found here.

If you are using SproutCore 1.10.1 or later, you can use the new sc-phantom command. This will handle invoking the test runner, passing through any arguments to PhantomJS.

If you are using 1.10.0 or are not using the gem, you will need to track down SproutCore’s installed location in order to run its test runner script. If you’ve got a copy checked out into your project’s frameworks directory, great! Just use that. If you’re using the gem, you’ll have to track it down yourself. It’s usually somewhere like ~/.rvm/gems/ruby-1.9.3-p374/gems/sproutcore-1.10.0 – if you’re unable to track it down, run gem env and look under the GEM PATHS heading for a hint.

Running the tests

First, start sc-server as you normally would. Once that is running, we can start the test runner. (If you are running SproutCore v1.10.0, replace sc-phantom with phantomjs $SC_PATH/lib/frameworks/sproutcore/phantomjs/test_runner.js in the following examples. See $SC_PATH note above for details.)

sc-phantom

By default, this will run all the unit tests that abbot knows about, including the tests in SproutCore itself. This is probably not what you want, so you can use the --include-targets flag to tell the test runner what tests you want to run.

For example, if your app is called todos, running

sc-phantom --include-targets=/todos

will run only the unit tests in your app. If you also have a framework you want to test, you can make the argument to –include-targets a comma-delimited list of targets:

sc-phantom --include-targets=/todos,/my_framework

There are a few other options available for excluding certains tests and only running certain types of tests (app, framework, etc). For the full list, run:

sc-phantom --help

It’s been noted often that there’s a serious lack of production-level SproutCore apps with readable source code. Developers often learn best by poking at something and seeing how it works, but until now there hasn’t been anywhere to go.

With an eye towards improving that situation, I’m excited to announce Juniper, a SproutCore app and annotated codebase. Check it out:

http://juniper.dcporter.net/

I wrote a fuller introduction here, and the source code itself is here.

If you’re new to SproutCore, or wondering if it’s right for your project, give it a poke! If you have any questions, say hi on the mailing list or on IRC. Any seasoned developers that want to give it a critical look-over should do so too – it’s intended as a showcase of possibilities and best practices, so if you spot something, hit me up in the GitHub Issues or directly.

(Juniper is inspired by Vesper, a really great note-taking app for the iPhone. If you have an iPhone and are underwhelmed with the built-in Notes app, you should check it out.)

Although it has been out for a couple weeks already, I had never officially announced the completion of the SproutCore Web Application Development book in this blog. So for anyone that has been waiting for a book on SproutCore, you should know that it has finally been completed and you can purchase a copy here.

This book covers almost every aspect of SproutCore with detailed explorations of the runtime environment, the MVC layers that SproutCore brings, using statecharts, interacting with multiple remote data stores and many many other topics all the way through to unit testing and deploying real SproutCore applications. So if you’re looking to take the next big leap in web software development and have ever been curious about SproutCore, now is your chance to learn everything you need to know in one easy read.

Thank you!

SproutCore 1.10.2 is now available. This is a patch level release and includes the following fixes:

• Fixed problems with keypress handling in IE8 and Opera.

• Fixed the swap transition plugin, SC.ContainerView.REVEAL, to properly reset the content view’s layout after transitioning out.

• Fixed a problem with SC.View.prototype.cancelAnimation(SC.LayoutState.CURRENT) that failed to stop at the proper top or left positions when using CSS transform animations when the top or left values were negative. This also improves the SC.ContainerView.PUSH transition, making it possible to push multiple content views without overlapping (see example).

• Fixed SC.ContentValueSupport to notify a change to each of the dependent content keys when the content changes entirely (i.e. the ‘*’ property changes).

• Fixed SC.SelectView to update correctly when its items collection is replaced.

• Fixed SC.AutoMixin to prevent the attributes from the former child views being applied to the latter child views.

• Fixed locally-scoped ‘and’ & ‘or’ bindings.

• Fixed a problem when the initial isEnabled value of a view is false, that failed to update the isEnabledInPane value of that view and its child views.

• Fixed the problem that setting the isEnabled value to true of a view which had disabled ancestors, could change the value of isEnabledInPane for that view to true.

• Fixed SC.TextFieldView being able to still be edited if it had focus at the same time that an ancestor view was disabled.

• Fixed the defaultTabbingEnabled property of SC.TextFieldView to actually prevent tabbing when the property is set to false. Also added insertBacktab handler support to interpretKeyEvents in order to prevent tabbing on shift-tab in SC.TextFieldView.

• Added missing support for touch events to SC.PopupButtonView.

• Fixed a bug that caused SC.TextFieldView hints to have a 0px line-height at times.

• Fixed a regression in collection views that prevented them from properly re-rendering when inside nested scroll views.

• Removed a duplicate listener on selectstart events in SC.RootResponder.

• Removed the jQuery ready hold in SC.platform that was used to delay launching of the app until the transition and animation event names tests completed. Several browsers will not run the transition/animations in hidden tabs, which slows and possibly blocks an app from launching. Since the results of these tests are used only to optimize the event listeners set up in SC.RootResponder, the code has been changed to setup the root responder at whatever point the tests successfully finish.

• Fixed picker panes failing to popup in the wrong place if they have some form of resizing. Added an observer to SC.PickerPane border frames so that the pane will re-position itself if it changes size.

• Removed the appearance of an undefined attribute in SC.TextFieldView.

• Fixed internal identification of IE7 to prevent any possible future version of Trident from being mistaken for IE7.

• Fixed a minor memory leak when manually removing event listeners from an element.

• Fixed a minor memory leak when using SC.InlineTextField.

This post is about one of the most important goals of SproutCore, making web app development easier and faster. SproutCore has always been largely about really fast app performance, but in many ways the performance benchmarks of a framework are only as good as the real world performance of the developers using that framework. Therefore, we wanted to highlight a number of recent additions to SproutCore purely for the purpose of helping developers create even faster SproutCore applications even faster.

For instance, one of the least publicized changes in version 1.10 is the large number of additional debugging statements in order to help guide developers to the source of any problems. These range from general warnings, prefixed with “Developer Warning:”, that should be fixed  before release, to outright errors prefixed by “Developer Error:” that must be fixed immediately.

For example, if you had a missing child view named in the childViews array previously it would throw an exception that had to be tracked down. In the latest version however, if your childViews array had a value “missingLabel” with no matching property for example, you would see the following in the console and your app would continue to run:

"Developer Warning: The child view named 'missingLabel' was not found in the view, SC.View:sc1247 (ATTACHED_SHOWN). This child view will be ignored."

Warnings like these serve to alert you of possible bugs without getting in the way of testing. In this case, a quick search for the value ‘missingLabel’ would highlight the source of the problem. There are also instances where a developer will do something unintentional that would cause unknown and hard to diagnose bugs in the app. For example, it was previously taboo to set the layerId property of a view, because this is how SproutCore maps view objects to DOM elements and if you ever accidentally created two views with the same layerId, your views would suddenly behave very strangely. However, with the new approach we can confidently use layerId in 1.10+, because if we ever accidentally used the same layerId twice we would see the following on the console with a full stack trace:

"Developer Error: A view with layerId, 'duplicateId', already exists.  Each view must have a unique layerId."

Of course, we fully leverage SproutCore’s development tools so that all of this debug code is stripped from production builds, so don’t worry about these messages adding to the code weight. In fact, in 1.10 we marked tens to hundreds of lines of existing debugging code for debug mode only at the same time as we added many new helpful messages. The overall result is a clearer debug process at the same time as a smaller production package.

Two other useful additions worth mentioning that came out shortly before 1.10 are the SproutCore Debug inspector pane for Chrome and the SproutCore package for Sublime Text 2. The first is a free addition for Chrome’s inspector that lets you inspect elements and easily see important information about the SC.View object of that element. Accessing the SC.View object in the console becomes as easy as having an element selected and typing $0v (or $0pv for the parent view). The second is a free package for Sublime Text 2 that adds several SproutCore specific snippets and automatically integrates in JSHint to flag JavaScript bugs early and enforce code cleanliness and consistency in your team.

Along similar lines, the docs have been built and packaged into the documentation browsing app Dash. Dash provides nice and fast local access to multiple doc sets.

As well, the SproutCore docs have seen a lot of love in 1.10 with many fixes, additions and the removal of any internal only docs. Of course there’s always room for improvement and work on the docs and guides continues each day. Fortunately, for those that want even more in depth detail on SproutCore right now, the first official SproutCore book is now available from Packt publishing.

So in conclusion, we hope that these additions make a positive difference for you in your own projects each day and please trust that many more improvements are on their way.

Note: Every part of SproutCore is open source, including the Website, Guides, Docs, Chrome inspector pane and Sublime Text 2 package. If you’d like to see even more improvement to any of these, please consider contributing yourself.